The current EDGE standard allows for two different Radio Link Control, RLC, modes of operation: acknowledged and un-acknowledged mode. In the un-acknowledged mode, data delays are kept at a minimum since there are no re-transmission delays, but bandwidth is wasted, since excessive channel coding must be used to guarantee acceptable Frame Error Rate, FER.
In the acknowledged mode on the other hand, data blocks are re-transmitted until correctly received, regardless of the delay requirements. Since the number of re-transmissions is unlimited, it is not possible to guarantee any maximum delay requirements by the acknowledged bearer. In addition, the transmission of the necessary control blocks containing the information regarding Acknowledge/Negative Acknowledge, ACK/NACK, may consume quite a large amount of bandwidth in the opposite direction, i.e. the “return” direction.
Within the framework of GERAN, GSM EDGE Radio Access Network, and Evolution in 3GPP, a non-persistent RLC operating mode, “NPM” mode, suitable for delay-critical services, will be included in the EDGE standard. This non-persistent mode is similar to the acknowledged mode operation, but with the difference that a timer is suggested for use in order to enforce a maximum allowed time from the reception of an RLC block until it must be delivered to the Logical Link Protocol, LLC, protocol layer above.
In current GERAN systems, the ACK/NACK information for acknowledged mode is sent in special control blocks, containing a starting sequence number and a bitmap representing radio blocks. The reporting strategy, e.g. how and when reports are sent etc., is controlled by the network. The mobile will send ACK/NACK information as a response to a poll from the base station. The poll will include information of when to send the control block, and the content of the report.
There are two reporting content possibilities, first partial bitmap, FPB, and next partial bitmap, NPB. An FPB report will start with the beginning of the receiver window, i.e. the oldest outstanding data block, while an NPB report starts at the point where the bitmap of the latest ACK/NACK report ended.
A drawback of the current ACK/NACK reporting protocols is that a full control block is needed every time ACK/NACK information is sent. Therefore the overhead will be large when frequent ACK/NACK information is needed for delay sensitive services.
Consequently, within the framework of GERAN Evolution in 3GPP, it has been suggested that a new ACK/NACK protocol should be introduced to GERAN. The suggestion is an event-based protocol that uses ACK/NACK messages that are “piggy-backed” on data packets in the opposite link direction. An event is defined as an error in the transmission detected by the receiver. This method has the potential to significantly reduce the re-transmission delay without significant overhead. International patent application PCT/SE 2006/050080 describes how these piggy-backed ACK/NACK Reports, “PANs”, can be designed as a combination of Block Sequence Numbers, BSN, which specify outstanding radio blocks, bitmaps giving ACK/NACK information of radio blocks after a specified BSN, and size bits or extension bits specifying the size of the ACK/NACK information. This method allows for the sent ACK/NACK information to consist either of one single PAN or be split into several multiple segment PANs.
However, in some cases, neither the existing standard, proposed standard changes, nor the previous patent application mentioned above may give sufficient information regarding which part of the RLC window to cover by means of the PANS in order to obtain the best performance for services which employ acknowledge mode and/or non-persistent mode radio bearers.
When using an event-based RLC operating mode with Piggy-backed ACK/NACK-information, PAN, the following issue may become of interest:
The First Partial Bitmap, FPB, and Next Partial Bitmap, NPB, reporting strategies do not guarantee that the BSN number that identifies the RLC block causing the event will be included in the PAN. With e.g. FPB, this BSN will not be included in the PAN until it has reached the lower end (lowest BSNs) of the RLC window, thus causing retransmission delays to become significantly larger.
For the delay-sensitive kind of services that use non-persistent radio bearers, this not only induces heavier jitter but may also be so late that the NPM transfer timer has already discarded the RLC block, which in turn will increase the Frame Error Rate, FER. For acknowledged mode services, there may be a potential risk of stalling the RLC transmit window, which may deteriorate the system performance and throughput.